Internet Info 1993/Internet Info CD-ROM (Walnut Creek) (1993).iso/inet/ietf/822ext/822ext-minutes-91nov.txt

Text File | 1993-03-11 | 13.3 KB | 349 lines

CURRENT_MEETING_REPORT_

Reported by Greg Vaudreuil/CNRI

Minutes of the Internet Message Extensions Working Group (822ext)

Agenda

   o Discuss and resolve outstanding issues in Quad-x
   o Discuss and complete the header character set proposal.


Minutes


  1. Resolve outstanding issues in Quad-X

     A list of outstanding issues was reviewed and amended.  Note, the
     term Quad-x was coined for RFCXXXX at this meeting, and is used
     throughout these minutes.


     (a) Audio format

         The Working Group was presented with two proposals for the
         format of audio/basic.  Both proposals were based on the NeXT
         audio formats, one had attributes in the content-type headers
         and the other had the attributes in the file header in the
         body.  After discussion, the Working Group concluded that it
         had no basis for choosing a standard #extensible# audio format
         and left the work for a future group.  The NeXT format was seen
         by many to be too machine dependent, and had too many options,
         even as profiled by Marshall Rose.

         A simple format was agreed to for audio/basic which has no
         options and is not extensible.  This definition for audio basic
         was defined as u- law, 1-channel, 8 khz.  The data in the
         bodypart is straight u-law.

     (b) Message integrity check

         The Working Group expressed a strong need to define a message
         integrity check for message bodies.  This was felt to be more
         general than would be available be adding a checksum to the
         base 64 encoding.  No clear specification was available at this
         meeting.  In the interests of making forward progress, the
         Working Group agreed that not having a MIC was not a show
         stopper, and if a solid proposal is ready, and can be approved
         by the list by December 16th, it would be included in the
         document.

         ACTION: Ned Freed and Jim Galvin -- Write a MIC proposal to

                                   1





    include the preferred MIC as suggested by the SAAG.

(c) Multipart/Alternative

    Multipart alternative was enthusiastically endorsed as a
    transition mechanism to encourage the sending richer formats
    than may otherwise be used.  By allowing a sender to send both
    a richly formatted document and include in a systematic way a
    simpler version, one which may be ``cat'ed'' to the screen,
    concern for the lowest common denominator will not have to be a
    restriction on the use of new features.

(d) Character set issues

    The Working Group specified the definition of a character set
    for the purposes of quad-x to be a unique mapping of a byte
    stream to glyphs, a mapping which does not require external
    profiling information.

    i. ISO 2022-jp

       ISO 2022 is not strictly speaking a character set.  It is a
       switching mechanism which requires an external profile to be
       useful, The Japanese have defined such a profile, and that
       profile will be documented and considered a character set
       for the purposes of Quad-x.

   ii. Mnemonic

       Keld Simonsen's mnemonic proposal as currently written
       requires the external specification of a character set and
       an escape character.  As such, it does not fit the general
       requirements of a character set.  A lunch sub-group defined
       a profile for mnemonic, with a lead in character of ``&''
       (ascii 38) and ascii as the default character set.  With the
       profile, the Working Group accepted mnemonic as a acceptable
       character set for Quad-x.

(e) Application specifications

    The Working Group agreed upon several criterion for the
    specification of new application subtypes to be defined in the
    quad-x proposal.  A new application must include in
    attribute-value pairs the profile, macro packages used, and any
    external pre-processors needed to use the included data.  The
    security implications of using the particular applications data
    without authentication must also be discussed.

    i. PostScript

       Adobe has defined Postscript in such a way that it does not

                              2





       require profiling information.  A security considerations
       section was written by Ned Freed, essentially pointing out
       the nature of the risk associated with file operations, and
       recommending that they be disabled.  Macintosh postscript
       files, which require laserprep header, as well as other
       postscript files generated by programs such as FrameMaker
       which call external libraries, must be sent with all such
       libraries prepended the mailed postscript to avoid the need
       to externally specify profiling information.

   ii. .nroff and TeX

       No person in the Working Group felt comfortable writing a
       complete profile for the use of either TeX or .nroff.  The
       specification of these popular applications was left as a
       future effort.

(f) Alphabet for boundary markers

    The current alphabet for boundary markers makes it difficult to
    construct markers which are compatible with RFC934 and existing
    digesting software.  The addition of space as a valid character
    would satisfy this need.  Further discussion resulted in the
    adoption of a more general alphabet, to include the invariant
    set of characters defined for the use of Base-64 to be used in
    boundary markers.  Trailing spaces are not permitted.  When
    spaces are used in a marker, the entire marker will have to be
    quoted in the header.

(g) Binary type definition

    An unscheduled discussion on the need for the Binary type was
    held.  With the clarification of the Applications type, and the
    difficulty of specifying exactly what initial content-types
    Binary should have, the Working Group without objection decided
    to drop it in favor of Application/Raw.

    This was a natural progression from the realignment of
    content-types in terms of system resources begun before the
    Atlanta meeting.  Application and Binary both require the
    ability to handle arbitrary Binary data, and require external
    programs to use the information.

(h) Application/External-Reference

    External Reference was seen by the Working Group to be a very
    useful feature, but as inadequately defined in Quad-x.  The
    current syntax provides no mechanism for multiple simultaneous
    retrieval mechanisms, the specification of syntax for
    mail-servers, or prioritizing the retrieval order.  The use of
    specific application/ftp and application/NFS when used with
    multi-part/alternative seems to be a reasonable approach, and

                              3





    was to be written up Borenstein.

    As with the MIC, this absence of this feature was not seen to
    be a show-stopper.  A new proposal will be submitted to the
    mailing list and if acceptable will be included in the
    document.

    ACTION: Nathaniel Borenstine -- Write up and submit to the
    mailing list a new proposal for application/external reference.


(i) Use of defaults

    The current quad-x document specifies defaults for only
    selected content-types.  In the case where defaults are not
    specified, and when the specified default may cease to be
    useful, possible ambiguity results.  A strong view expressed
    before this meeting by Dave Crocker was supported by most
    attendees that defaults should be prohibited and that the
    subtype should always be specified.  For broken mail which is
    send with incomplete content-types, behavior of the reader is
    left up to the implementor and user.  It was felt that because
    the message was already ``broken'' any uniform assumption could
    not be reliable.

(j) Portable End-Of-Line markers in base 64

    The Working Group deleted end of line markers in Base 64,
    leaving it to the specific content-type to define the semantics
    of end of record.  This decision has the advantage of restoring
    symmetry and transport independence between Base 64 and
    Quoted-Printable

(k) Compression

    Compression was raised in the context of the Binary content
    type.  Participants have expressed a desire, and the pragmatic
    realization that the use of ``compressed, uuencoded, tar''
    files will continue to be sent and need to be indicated in the
    message.  The Working Group previously stated it's preferences
    and rational for not supporting uuencode, but has never clearly
    expressed it's position on compress.  The issue was tabled
    pending a proposal to be sent to the mailing list.  Again, if
    the proposal is acceptable it will be included, and it's
    absence was not a show-stopper.

    ACTION: Neil Katkin -- Draft a proposal for the use of the
    compress algorithm in the Quad-X proposal.

    i. Internal reference in richtext



                              4





          A proposal was made at this meeting to expand the richtext
          definition by including an internal-reference token.  It was
          envisioned that this token would allow the insertion of
          objects in other parts of the message into the richtext
          stream.  While many people supported this idea, no concrete
          proposal was submitted.  If a proposal is approved by the
          mailing list, it will be included in the document.

          ACTION: Harri Salminen -- Draft a proposal for Internal
          reference in the richtext content subtype.

       Timetable for completion

       With the conclusion of the meeting, five issues were left open.
       A new version of Quad-x, along with the proposals for the open
       issues are due on December 6th.  A new Internet Draft is
       expected at that time.  The final comment period will end with
       the posting of a final version of Quad-x in the first week of
       January when the Working Group will submit the document to the
       IESG for Proposed Standard Status.


2. Header character set proposal

   The Working Group began a review of the proposal submitted by Keith
   Moore to include character set identification and encoding
   information in the headers of a document.
   The discussion was unstructured resulted in a productive stream of
   consiousness review.  The Working Group approved of the general
   approach and with the changes discussed, approved the proposal.
   Below are the main issues discussed and their resolution.
   ED NOTE: Please help me reconstruct this discussion and submit text
   for these minutes!

   (a) Multiple encoded words

       The Working Group felt that it should be acceptable to use
       multiple encoded words.  Furthermore, the Working Group agreed
       that the length of encoded words should not be limited by this
       document, but rather by implementors of software in
       consideration of the pragmatic guidelines in the Quad-x
       document.

   (b) Character set names

       The Working Group committed to alligning the character set
       names between the header document, Quad-x and Simonsen's
       charset document.  The use of the numeric identify was dropped,
       both as a result of allowing longer lines by specifying
       multiple encoded words, and out of consideration in making the
       encoded word more user-readable with old software.


                                 5





     (c) Use of Spaces in encoded words

         Keith?
         Megan, If I do not send you text for this section, just delete
         it.

     Timetable for completion

     This document will be alligned with Quad-x, and a new version will
     be submitted to the Internet Drafts directory by December 6th.  At
     that time, the Working Group may decide to combine the two
     documents, or progress them jointly as a single standard.  In any
     event, the Working Group committed to the submission of the header
     document and Quad-x as a bound set.


Attendees

Harald Alvestrand        [e-mail]
Mary Artibee             [e-mail]
Nathaniel Borenstein     [e-mail]
Ronald Broersma          [e-mail]
Cyrus Chow               [e-mail]
James Conklin            [e-mail]
Robert Cooney            [e-mail]
Mark Crispin             [e-mail]
Erik Fair                [e-mail]
Ned Freed                [e-mail]
James Galvin             [e-mail]
Jisoo Geiter             [e-mail]
Russ Hobby               [e-mail]
William Jackson          [e-mail]
Borka Jerman-Blazic      [e-mail]
William Jolitz           [e-mail]
Neil Katin               [e-mail]
Tom Kessler              [e-mail]
Jim Knowles              [e-mail]
Vincent Lau              [e-mail]
Eliot Lear               [e-mail]
Gordon Lee               [e-mail]
Jack Liu                 [e-mail]
Paul Milazzo             [e-mail]
Keith Moore              [e-mail]
Mark Needleman           [e-mail]
Daniel Newman            [e-mail]
Michael Patton           [e-mail]
Harri Salminen           [e-mail]
Keld Simonsen            [e-mail]
Gregory Vaudreuil        [e-mail]



                                   6